Resource and Information Flow Security Requirements

ion from any particular JVM implementation. This implementation of JML’s heap space support in ESC/Java2 has uncovered interesting problems concerning the interaction between the ”\working space” specification function and the machine state in which it is evaluated. Compilation from JML to a specification language for bytecode has been carried out at INRIA Sophia in the context of using program logic to specify and verify statically precise memory consumption policies for Java bytecode programs [8]. This explicitly favours precision of the analysis at the cost of the automation. In particular, specifications are written in BML [16]. BML is based on the design principles of JML and supports a representative subset of the latter, while adding primitives for stack expressions. It allows the user to express: 1. inter-method specification as for instance, method pre and postconditions, frame conditions; 2. class specification: history constraints and class invariants; 3. intra-method specification: assertions at certain program points in the method body including loop invariants. Thus, BML is expressive enough for most purposes including the description of non trivial functional and security properties. It has been used to specify precise memory consumption policies for (sequential) Java applets. JML annotations are translated into BML annotations by a compiler that can be used in combination with most Java compilers to produce extended class files from JML-annotated Java source programs. The verification condition generator based on the weakest precondition calculus and the compiler are implemented and integrated in the Java Applet Correctness Kit (JACK) [17]. Additional work concerns the issue of inferring some of the annotations required to express the memory consumption policy. Resource policies Further work ([4]) explores a way of generalising a proof-carrying code infrastructure to include resource policies based on assertions on byte code, rather than a on fixed format. Two forms of policy are used: guaranteed policies which come with proofs and target policies which describe limits of the device. A guaranteed policy is expressed as a function of a methods input sizes, which determines a bound on consumption of some resource, for example: “for positive integer inputs n and m, executing the method call calc(int m,int n) requires at most 16 + 42 ∗ m+ 9 ∗ m ∗ n JVM instructions to be executed.” A target policy is defined by a constant bound and input constraints for a method. For example: “for all inputs n < 10 and m < 10, executing the calc(int m,int n) method must take no more than 2000 instructions.” A recipient of mobile code chooses whether to run methods by comparing between a guaranteed policy and the target policy. Since delivered code may use methods implemented on the target machine, guaranteed policies may also be provided by the platform; they appear symbolically as assumptions in delivered proofs. Guaranteed policies entail proof obligations that must be established from the proof certificate. Before proof, a policy checker ensures that the guaranteed policy refines the target policy; delivered policies thus mediate between arbitrary target requirements and the desirability to package code and certificate only once. Policies are naturally treated as special cases of assertions, in particular, to allow an efficient check of whether mobile code supplied with a guaranteed policy implements the target policy of particular device. To this end, [4] introduced syntax and semantics for the above two forms of policy embedded as Java permissions in Java security policy files. Then checking policy conformance is reduced to a sound check that the code satisfies the guaranteed policy claimed for it (delivered with the certificate) and that policy implies the policy desired by the client. The security model here is quite analogous to the present security mechanisms in Java, where code is implicitly supplied with its ”code base” (origin) that may be checked against permitted code bases, and where code may be supplied with cryptographic signatures, and these signatures may be accepted according to the policy.